OPC Studio User's Guide and Reference
Browse Path and Node Id Resolution
Items in OPC Data Access are ultimately identified by their item IDs (node IDs), which are strings defined by the server. Their syntax is not standardized, and although they commonly look like a sequence of names or numbers with some separators interspersed (such as “Boiler.Drum1001.LIX001.Output”), there is no general way to construct the item IDs without browsing the OPC server’s address space.
In OPC-UA, nodes have their Node Ids, which are a bit more complex (they are qualified by a namespace, and can be of several types, not just strings) – but effectively, they behave similarly. Their values are not generally standardized; they are completely determined by the concrete OPC-UA server you are connecting to.
When mapping, you could specify the precise node ID with the DANode (or UANode) attribute. This may work in some scenarios, but has severe limitations. The OPC address space (and your object structure) typically contains repeated patterns of nodes that are just placed differently. You want to define and map object types that match these patterns, but because the OPC node IDs will differ based on the placement of the pattern in the OPC address space, you won’t be able to tell a unique item ID for each member.
This problem can be solved by using browse paths – sequences of item names that start from a known place in the OPC address space (e.g. in its root). The names in browse paths are “short” names that are used when browsing and sometimes displayed to the user, and the “short” node name typically remains the same if the node with the same meaning (a part of node pattern) is placed differently in the OPC address space. The mapping can translate the browse paths to item IDs when they are actually needed. For more on browse paths, see 4.11.7Browse Paths.
In order to specify nodes using a browse path, use the BrowsePath argument of the DANode (or UANode) attribute. It is a string that can contain an absolute or relative browse path. An absolute browse path string has similar limitations as the item ID; you may find it useful to define the starting point for the mapping (always needed in OPC-UA), or if the mapping does not start at the root of the OPC address space (in OPC Classic), though.
With a relative browse path string, you can specify that the member annotated with DANode (or UANode) attribute will belong to an OPC node that is based on the current OPC node, but appended with the relative browse path given. The relative browse path string can contain a single “short” item name, or multiple separated names forming a longer path.
For example, if the current OPC node (for the parent) in OPC Classic is given by browse path ‘/Boiler/Drum1001/LIX001’, and your member is annotated with DANode attribute with BrowsePath = “Output”, the OPC node for the member will be given by a browse path ‘/Boiler/Drum1001/LIX001/Output’, which can then be translated to a full item ID. When the same type containing your member is used within a different context (at different place in the OPC address space), the resulting browse path will be different, but still contain “Output” node at the end. This is how repeated node patterns can be mapped without having to specify the individual item IDs.
By default, when the DANode (or UANode) attribute is used without further arguments, the name of the member being annotated is used as the relative browse path string for the DANode (or UANode) attribute. This means that if you name your members the same as the nodes in the OPC address space, you do not have to provide any additional arguments to the DANode (or UANode) attribute. This is a common practice, but if some members cannot follow it, you can still specify a different browse path just for them.
In some cases, the use of browse paths is not possible or practical, but you can define a “rule” specifying how the node IDs are constructed for the concrete OPC server and concrete part of its address space. In such case, you can use the DAItemIdTemplate (or UANodeIdTemplate) attribute to annotate your type, giving it an ItemIdTemplateString (or a NodeIdTemplateString, in OPC-UA) argument that specifies how a node ID of a node is made of the parent node Id, and browse name of the node being mapped (a member name, typically).
Following macros can be used in template strings for DAItemIdTemplate attribute:
Following macros can be used in template strings for UANodeIdTemplate attribute:
Final note: In OPC Classic, it is possible to specify combinations of BrowsePath and ItemId arguments of the DANode attribute, and further combine it with the DAItemIdTemplate attribute. In OPC-UA, it is possible to specify combinations of BrowsePath and NodeId arguments of the UANode attribute, and further combine it with the UANodeIdTemplate attribute.
In such cases, the information specified at the “deepest” level prevails. If both the browse path and node ID are specified for a node, then both are passed to the underlying OPC client object for processing. Which one of them will be finally used depends on many factors, including the concrete capabilities of the server and the version(s) of OPC specifications it conforms to, so in such case, you are responsible for guaranteeing that both the browse path and the item ID represent the same node.